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ABSTRACT 

Many  challenges  have  emerged  within  the  past  five  years 
for  both  military  customers,  as  they  plan  for  and  pur- 
chase aircraft,  and  for  manufacturers,  in  producing  these 
aircraft.  Opportunities  to  develop  new  models  of  mili- 
tary rotorcraft  have  decreased  with  steady  reductions  in 
military  budgets  and  the  post  cold-war  environment. 
These  budget  reductions,  coupled  with  quantum  ad- 
vances in  computing  technologies  that  have  advanced 
ground-based  and  airborne  processing  power,  have 
shifted  the  focus  of  military  customers  from  new  model 
development  to  increased  aircraft  performance  via  sys- 
tem upgrades  and  training. 

The  emphasis  on  meeting  long-term  operational  needs 
with  these  upgraded  systems  and  the  training  required  to 
optimize  their  use  has  resulted  in  an  imperative  to  change 
acquisition  and  implementation  strategies  for  both  the 
aircraft  customer  and  the  prime  manufacturer.  This  pa- 
per focuses  on  the  impact  of  these  strategies  on  the  rotor- 
craft  industry,  as  follows: 

Systems  Engineering.  The  architecture  of  aircraft 
mission  equipment  packages  must  be  carefully 
planned  in  order  to  provide  the  capability  of  rapid 
and  cost-effective  modifications  and  upgrades.  Avi- 
onics architectures  have  long  supported  highly  fed- 
erated mission  processing  furnished  by  suppliers 
with  highly  proprietary  technical  solutions.  These 
complex  closed  subsystems  cannot  be  modified  or 
upgraded  without  considerable  expense,  and  solicit- 
ing equivalent  functionality  from  other  suppliers  is 
cost-prohibitive.  Re-engineering  the  supply  chain 
process,  scrutinizing  avionics  make-buy  decisions, 
and  concentrating  systems  engineering  activities 
early  in  development  programs  can  aid  in  satisfacto- 
rily and  predictably  meeting  the  long-term  opera- 
tional needs  of  both  the  military  customer  and  the 
manufacturer. 

Aircraft-level  integration  facilities.  Ground-based 
systems  integration  solutions  must  supplant  aircraft 
testing  to  the  maximum  practicable  extent  in  order  to 
accommodate  rapid  and  economical  test  results 
without  expending  valuable  aircraft  time.  Systems 
integration  test  stations  that  combine  aircraft  sub- 
systems with  subsystem  emulations,  math  model 
simulation,  and  playback  capability  can  provide  a 


high  degree  of  fidelity  to  on-ground  testing,  both 
prior  to  first  flight  and  during  the  aircraft  flight  test 
program. 

Training  systems.  Training  for  pilots,  crews,  and 
maintainers  must  move  to  improved  on-ground 
training  systems,  such  as  full  flight  simulation  train- 
ers and  non-motion  cockpit  trainers.  In  order  to 
make  the  rapid  changes  required  to  keep  trainers 
current  with  fielded  aircraft,  these  trainers  must  also 
be  developed  utilizing  a concept  of  optimizing  open 
systems  architectures  and  commercial  off-the-shelf 
hardware  and  software.  With  fewer  aircraft  being 
purchased  and  more  complex  mission  equipment  in 
development,  on-ground  training  solutions  can  pro- 
vide aircraft  personnel  tools  for  becoming  familiar 
and  proficient  with  their  tasks  off  the  aircraft. 

INTRODUCTION 

Today’s  military  customer  wants 

• An  affordable  airplane 

• That  meets  performance  requirements  now, 

• Has  incremental  performance  upgrades  planned  that 
are  affordable  and  schedule-efficient,  and  that  also 

• Has  training  for  crew  and  maintainers  that  is  concur- 
rent and  economical. 

Some  of  the  processes  that  can  be  utilized  to  maximize 

the  ability  to  satisfy  customer  requirements  are 

1 . Strong  systems  engineering  focus  at  the  inception  of 
upgrade  program  planning  that  provides  specific  and 
quantifiable  performance  requirements  such  that  the 
mission  equipment  package  architecture  and  top- 
level  requirements  can  be  allocated  to  subsystems 
very  early  in  the  program. 

2.  Robust  aircraft- level  systems  integration  testing  to 
eliminate  common  problems  that  can  be  resolved 
prior  to  first  flight,  to  provide  confidence  that  air- 
craft subsystems  are  interacting  correctly  and  pre- 
dictably prior  to  aircraft  installation,  and  to  support 
identification  and  resolution  of  problems  after  the 
aircraft  has  been  fielded. 


Paper  presented  at  the  RTO  SCI  Symposium  on  "Aircraft  Update  Programmes.  The  Economical  Alternative?”, 
held  in  Ankara,  Turkey,  26-28  April  1999  and  published  in  RTO  MP-44. 
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3.  Training  devices,  including  engineering  simulation 
and  flight  training  devices  with  and  without  motion. 
These  trainers  provide  familiarization  with  the  air- 
craft that  can  be  performed  prior  to  aircraft  fielding, 
and  reduce  costs  associated  with  utilization  of  the 
aircraft  itself. 

SYSTEMS  ENGINEERING  PROCESS 

Every  aircraft  manufacturer  has  a long  history  in  cockpit 
development  programs  and  projects  that  have  failed  be- 
cause their  systems  engineering  was  not  sufficient  to 
specify  and  allocate  requirements  that  would  meet  the 
military  customer’s  short-  and  long-term  needs.  For  this 
systems  engineering  process  to  be  successful  requires 
communication  between  customer  and  aircraft  manufac- 
turer very  early  in  the  aircraft  conception  period,  an  or- 
derly and  disciplined  formulation  of  mission  equipment 
architecture  and  expected  function,  intelligent  competi- 
tive procurement,  and  strong  technical  oversight  follow- 
ing the  procurement  period  from  both  the  customer  and 
the  aircraft  manufacturer. 

It  is  difficult  to  assess  the  success  of  the  systems  engi- 
neering process,  because  the  program  must  be  concluded 
prior  to  being  able  to  measure  the  results  of  the  effort. 
This  means  that  successful  systems  engineering  requires 
an  up-front  investment  in  cost  and  schedule — which 
mandates  trust  and  commitment  by  both  the  customer 
and  aircraft  manufacturer,  with  no  guarantee  of  success. 
Bell  Helicopter  Textron  Inc.  has  participated  in  many 
aircraft  and  systems  upgrade  programs — with  varying 
levels  of  success. 

At  the  completion  of  any  aircraft  development  or  up- 
grade activity,  a systematic  review  should  be  undertaken 
to  provide  insight  into  the  management  of  subsequent 
programs: 

• How  producible  are  the  subsystems? 

• How  does  the  modified  aircraft  cockpit  reduce  crew 
and  maintainer  workload? 

• How  easily  modified  are  the  cockpit  systems  from 
this  point  forward? 

• How  capable  are  the  subsystem  suppliers  in  repeat- 
ing previous  success? 

• How  have  the  subsystem  suppliers  addressed  tech- 
nology obsolescence? 

This  review  cannot  take  place  until  the  mission  equip- 
ment package  has  been  deployed  for  a time  period  suffi- 
cient for  early  box  failures  and  customer  evaluation  to 


have  taken  place,  and  by  that  time,  most  aircraft  manu- 
facturers are  committed  to  other  development  programs. 

As  the  benefits  of  systems  engineering  have  become  evi- 
dent, Bell  has  developed  some  guidelines,  with  the  aid  of 
internal  investments  in  process  and  product  improve- 
ments, that,  over  the  past  three  years,  have  yielded  posi- 
tive results  in  expertise  and  in  potential  repeatability  of 
success. 

Improvements  have  been  made  in  the  following  three 
areas: 

• Mission  Equipment  Package  planning 

• IR&D  involvement  for  future  benefits  in  systems 
engineering,  in  particular 

1.  Process  improvements 

2.  Product  development  knowledge 

• Supplier  selection 

Mission  Equipment  Package  Planning 

In  the  area  of  Mission  Equipment  Package  planning, 
technical  and  management  involvement  with  the  cus- 
tomer to  understand  and  clarify  a near-  and  long-term 
vision  for  the  aircraft  upgrade  has  been  highly  success- 
ful. On  the  H-l  Upgrade  program.  Bell  and  NAVAIR 
set  up  complementary  team  structures  within  each  of 
their  organizations,  called  Integrated  Product  Teams, 
which  conducted  trade  studies  to  determine  the  optimal 
mission  equipment  package  to  meet  customer  desires 
while  fitting  into  their  funding  profile.  This  structure 
was  assembled  prior  to  any  avionics  supplier  selection 
and  allowed  aircraft  requirements  to  be  logically  allo- 
cated to  subsystems  along  with  targets  for  weight,  cost, 
reliability,  and  maintainability. 

Bell  employs  this  methodology  on  other  cockpit  devel- 
opment programs  for  the  military,  as  well  as  on  commer- 
cial programs,  where  Bell  considers  the  Federal  Aviation 
Authority  (FAA)  to  be  the  customer.  Forming  a working 
team,  consisting  of  management  and  technical  contribu- 
tors, early  in  the  program  allows  the  mission  equipment 
package  architecture  to  be  defined  and  decisions  made 
such  as  federated  versus  distributed  subsystems,  make 
versus  buy,  and  subsystem  vendors,  and  culminates  in  a 
program-level  Preliminary  Design  Review.  This  Pre- 
liminary Design  Review  signifies  the  time  at  which  all 
requirements  are  understood  by  the  airframe  manufac- 
turer and  subsystem  suppliers,  and  at  which  the  customer 
understands  the  limitations  of  the  manufacturer  and  sup- 
plier solutions.  At  this  point,  there  should  be  confidence, 
if  the  systems  engineering  process  has  been  employed 
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well,  that  the  probability  of  successful  implementation 
on  the  aircraft  is  high. 

This  process  has  worked  well  on  the  H-l  Upgrade  Pro- 
gram, as  well  as  the  V-22  program  and  its  variants,  also 
deliverable  to  the  U.S.  Navy  and  Marines.  On  the  H-l 
Upgrade  Program,  robust  systems  engineering  led  to  the 
selection  of  Litton  as  the  major  cockpit  system  supplier, 
with  ancillary  suppliers  for  other  airborne  systems.  In 
addition,  informed  trade  studies  resulted  in  the  Bell  in- 
house  development  of  the  H-l  Flight  Control  System 
(FCS)  and  two  types  of  interface  processing  units,  called 
Wiring  and  Integration  Remote  Terminals  (WIRT). 

As  a more  detailed  example  of  proficient  systems  engi- 
neering with  long-tenn  supportability,  the  H-l  Upgrade 
Program  FCS  is  identical  for  both  UH-1Y  and  AH-1Z 
aircraft,  and  needs  only  two  card  types  to  meet  its  func- 
tional specifications:  a CPU  card  and  an  axis  card.  The 
current  customer  requirement  for  a three-axis  system 
uses  one  CPU  card  and  three  identical  axis  cards,  and  a 
fourth  (with  accompanying  power  supply)  can  be  added 
into  the  spare  card  slot  if  a fourth  axis  is  funded  by  the 
customer  in  future.  The  design  of  these  subsystems 
within  Bell  were  leveraged  from  an  on-going  IR&D 
project,  which  is  detailed  in  the  following  section. 

IR&D  involvement  for  future  benefits  in  systems  en- 
gineering 

Bell,  since  1995,  has  focused  a portion  of  its  internal 
research  and  development  (IR&D)  funding  on  improve- 
ments in  systems  engineering,  specifically  in  areas  of 
process  improvement  and  in  product  development 
knowledge. 

Process  improvements.  Two  sets  of  activities  have 
raised  awareness  and  increased  the  knowledge  base 
within  Bell  of  our  internal  systems  engineering  proc- 
esses, and  have  provided  a framework  for  improving  the 
aircraft  mission  equipment  development  process  on  fu- 
ture programs.  These  investments  have  yielded  excellent 
results,  as  described  below: 

1 . Independent  capability  assessments  via  the  Carnegie 
Mellon  Software  Engineering  Institute  (SEI)  Soft- 
ware Capability  Maturity  Model,  both  for  technical 
oversight  of  suppliers  and  for  in-house  software  de- 
velopment efforts.  The  entire  Systems  Integration 
organization  at  Bell  was  assessed  in  August  1996  at 
a high  Level  1 (Initial),  and  reassessed  in  October 
1997  at  Level  2 (Repeatable),  both  times  by  an  inde- 
pendent consulting  agency.  The  Systems  Integration 
organization,  which  includes  all  system  design  areas 
(avionics,  armament,  electronic  warfare,  flight  con- 
trols, and  electrical  systems)  and  hardware,  soft- 
ware, and  test  design  capability  for  these  systems, 
expects  to  achieve  Level  3 (Managed)  at  their  next 


assessment  scheduled  for  August  1999.  This  com- 
mitment to  improve  internal  processes  and  to  ac- 
tively seek  objective  assessments  of  these  processes 
has  driven  Bell  to  make  their  systems  and  software 
processes  and  the  technical  management  of  their 
avionics  system  suppliers  consistent  between  proj- 
ects and  has  provided  guidelines  for  training  the  en- 
gineering staff. 

2.  Benchmarking  activities  were  conducted  in  1998  by 
a Design  & Producibility  Team,  staffed  with 
Engineering  and  Manufacturing  personnel  tasked 
with  evaluating  the  development  process  in  the 
industry,  as  it  existed  in  key  companies.  This  team 
conducted  benchmarking  throughout  aerospace  and 
related  industries  to  identify  “best  in  class”  practices 
to  be  adopted  at  Bell  for  reducing  schedule  and  cost 
in  aircraft  development  and  upgrade  programs.  This 
benchmarking  activity  has  resulted  in  the 
formulation  of  a development  template  for  measured 
and  concurrent  product  development  and  upgrades 
which  tie  all  responsible  functional  areas  together 
to  reduce  traditional  schedule  and  cost  impacts. 
This  template  will  be  utilized  to  predict  future 
program  costs  based  upon  historical  data,  and  will 
increase  the  repeatability  of  success  on  subsequent 
programs. 

Product  development  knowledge.  The  Advanced  Sys- 
tems and  Technology  Integration  (ASTI)  program  was 
initiated  in  1996,  in  part  to  provide  insight  into  the  use  of 
a generic  avionics  architecture,  and  to  provide  a series  of 
prototype  hardware  and  software  components  that  can  be 
easily  migrated  into  flightworthy  components.  The  goals 
of  this  IR&D  program  were  twofold:  to  keep  in-house 
development  capabilities  current  with  technology,  and  to 
make  Bell  engineering  “smart  managers”  in  the  area  of 
technical  supplier  oversight  for  complex  airborne  sys- 
tems. 

There  were  three  main  areas  of  avionics  hardware  and 
software  investigated:  data  acquisition  systems,  instru- 
ment display  systems,  and  mission  computers.  Within 
each  of  these  areas  the  following  topics  were  examined: 
use  of  commercial  off-the-shelf  (COTS)  hardware  and 
software  components,  improved  system  and  software 
development  toolsets,  and  open  system  architectures. 
The  efforts  of  the  ASTI  program  have  thus  far  resulted  in 
the  following  accomplishments: 

1.  Dual  use  (for  both  military  and  commercial  applica- 
tions) data  acquisition  system  hardware  and  software 
using  COTS  components. 

2.  Generic  object-oriented  display  software  compo- 
nents for  design,  evaluation,  and  real-time  use  in  in- 
strument display  systems. 
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3.  Increased  awareness  of  the  advantages  of  open  sys- 
tem architectures. 

Recent  focus  by  the  military  on  the  reduction  of  devel- 
opment costs,  the  increased  use  of  commercial  off-the- 
shelf  (COTS)  parts  and  processes,  the  use  of  improved 
system  and  software  processes,  and  the  design  of  open 
system  architectures,  has  resulted  in  changes  in  the  sub- 
system development  process.  The  COTS  label  encom- 
passes more  than  using  industry  standard  components;  it 
also  entails  using  industry  standard  systems,  processes, 
and  tools.  Improved  software  processes  and  toolsets 
focus  on  increased  software  reuse,  maintainability,  and 
customer  satisfaction,  using  open  system  architecture  as 
the  foundation  for  facilitating  these  initiatives. 

Integrating  COTS  components  into  military  designs  re- 
quires determining  how  to  modify  a military  design  to 
use  COTS  components  as  well  as  how  to  modify  the 
COTS  components  to  work  in  a military  design.  Thus 
far,  the  use  of  COTS  in  the  military  has  mostly  been  at 
the  component  level.1  However,  there  is  much  more  to 
be  gained  if  industry  standard  systems,  processes,  and 
tools  can  be  employed  as  well.  An  example  of  using 
industry  standard  tools  might  be  the  choice  of  C,  C++,  or 
Pascal  compilers  as  opposed  to  past  military  standards 
such  as  Jovial  or  Ada.  Another,  potentially  much  more 
beneficial,  approach  to  integrating  COTS  components  is 
the  concept  of  dual  use.  Dual  use  is  the  idea  of  devel- 
oping systems  that  can  be  used  in  both  commercial  and 
military  applications,  thus  attaining  the  benefits  of 
coproduction.  The  benefits  of  using  COTS  components 
and  systems  in  military  products  must  be  carefully 
weighed  against  compromising  essential  military  specific 
requirements. 

Open  system  architecture  “is  an  architectural  framework 
defined  by  Open  Systems  interface  standards.  Open 
Systems  standard  interfaces  are  clearly  and  completely 
defined  interfaces  that  support  interoperability,  portabil- 
ity, and  scalability.”2  The  application  of  open  system 
interface  standards  should  be  an  integral  part  of  the  de- 
sign process.  Although  using  standard  interfaces  is  the 
key  to  designing  successful  open  system  architectures, 
the  selection  of  interface/firewall  locations  is  also  im- 
portant. Selecting  appropriate  interface  points  in  the 
system  may  allow  subsystem  and/or  component  reuse 
and/or  upgrade  with  relative  ease.  The  personal  com- 
puter market  is  an  extraordinary  example  of  how  open 


1 Nordwall,  Bruce  D.,  “Buying  Off-the-Shelf  Challenges 

Military,”  Aviation  Week  and  Space  Technolog v,  Vol. 
146,  (1 8):57— 59,  April  28,  1997. 

2 Roark,  Chuck  and  Kiczuk,  Bill,  “Open  Systems  - a 
process  for  achieving  affordability,”  IEEE  Aerospace 
and  Electronics  Systems  Magazine , Vol  12,  February 
2,  1997,  pp  26-32. 


system  architectures  can  lead  to  efficient  development  of 
new  products. 

The  Bell-funded  ASTI  program  identified  COTS,  sys- 
tem/software process,  and  open  system  architecture  top- 
ics and  investigated  their  application  to  helicopter  avi- 
onics components: 

Data  Acquisition  Systems.  The  data  acquisition  unit 
(DAU)  is  a system  that  is  connected  to  a variety  of  sen- 
sors and/or  discretes  for  data  collection.  Each  analog 
input  is  digitized  through  an  analog-to-digital  (A/D)  con- 
verter, and  then  output  for  display  or  further  processing 
using  either  a MIL-STD-1553  or  ARINC  429  data  bus. 
Likewise,  each  discrete  input  is  either  acted  upon  inter- 
nally or  passed  on  for  display  or  further  processing.  The 
DAU  can  also  provide  several  ancillary  functions,  such 
as  storing  system  exceedences  and  stick  shaking. 

Several  COTS  options  were  investigated  for  use  in  the 
DAU.  As  is  common,  the  main  use  of  COTS  was  at  the 
component  level.  All  A/D,  D/A,  and  processor  cards 
were  designed  using  COTS  components,  where  possible. 
Various  COTS  input/output  (I/O)  boards  were  consid- 
ered; however,  none  had  the  necessary  channel  capacity. 
Likewise,  COTS  processor  cards  were  considered,  but 
the  unit  cost  for  them  was  typically  too  high.  The  sys- 
tem’s power  supply  was  a selection  from  industry  stan- 
dard off-the-shelf  components.  In  conjunction  with 
DAU  development,  several  industry  standard  off-the- 
shelf  sensors  (such  as  temperature  bulbs,  strain  gauge 
pressure  transducers,  and  chip  detectors)  were  identified 
and  implemented  across  multiple  platforms. 

During  the  process  of  DAU  development,  multiple  in- 
dustry standard  processes  and  tools  were  used.  Follow- 
ing is  a sample  listing  of  tools  and  their  use: 

• DOORS'  - System  requirements  management  and 
traceability. 

• VIEWlogic®  - Hardware  schematic  design. 

• PADS"  - Hardware  trace  routing. 

• Green  Hills"  C - Software  development  environ- 
ment. 

• LDRA"  - Software  testing. 

• PVCS"  - Configuration  management. 

Many  open  architecture  ideas  were  also  investigated 
during  development  of  the  DAU.  The  chassis  was  de- 
signed for  standard  VME  6U  form  factor  cards.  A stan- 
dard VME  backplane  was  investigated;  however,  the 
VME  standard  did  not  provide  the  necessary  undedicated 
I/O  lines  for  sensor  input.  The  VME  6U  form  factor  card 
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size  was  chosen  to  allow  inclusion  of  other  existing 
VME  6U  boards  into  the  chassis  if  desired  at  a later 
point.  The  DAU  was  designed  with  two  data  output  in- 
terface protocols:  ARINC  429  and  MIL-STD-1553.  This 
has  allowed  dual  use  of  the  design  for  commercial  and 
military  projects. 

The  investigation  into  a data  acquisition  system  has  been 
a tremendous  success.  It  has  resulted  in  the  DAU’s  in- 
clusion in  the  current  H-l  Upgrade  Program,  in  the  form 
of  the  Flight  Control  System  (FCS),  as  well  as  two  types 
of  WIRT  units,  which  serve  as  electronic  interface  units 
that  process  a variety  of  discrete  and  analog  sensor  inputs 
throughout  the  airplane.  A variation  of  the  DAU  has  also 
been  used  in  the  commercial  Bell-Agusta  Model  609  tilt- 
rotor  program,  as  the  Ice  Protection  Control  System.  The 
risk  reduction  benefit  of  the  ASTI  program  has  ensured 
qualified  H-l  FCS  and  WIRT  units  prior  to  scheduled 
aircraft  needs  within  cost  targets.  Fig.  1 shows  the  DAU 
system  architecture  as  defined  on  the  ASTI  program, 
with  generic  serial  bus  interface  capability  for  dual  use. 

Instrument  Display  Systems.  The  instrument  display 
system  (IDS)  is  a system  that  graphically  displays  digital 
and  analog  engine,  transmission,  electrical,  outside  air 
temperature,  clock,  and  fuel  system  information,  for- 
merly displayed  on  multiple  analog  gauges.  It  also  pro- 
vides an  interface  for  data  entry  related  to  various  ship 


configuration  and  flight  parameters,  such  as  fuel  tank 
configuration  and  weight  distribution,  as  well  as  a main- 
tenance mode  interface  to  access  stored  engine  parame- 
ters and  engine  exceedence  information.  Fig.  2 depicts 
the  system  architecture  for  the  IDS. 

The  digital  flat  panel  display  also  allows  the  use  of  mul- 
tiple colors  to  indicate  normal,  caution,  and  danger 
ranges.  Fig.  3 shows  a sample  IDS  display  in  black  and 
white.  The  IDS  engineering  evaluation  unit  created 
during  the  ASTI  investigation  was  developed  almost 
entirely  from  COTS  components.  DY4°  VME-based 
CPU  and  graphics  cards  were  used  to  generate  the 
graphical  objects,  simulate  the  input  signals,  and  simu- 
late the  MIL-STD-1 553/AR1NC  429  interface.  Two 
Sharp6  flat  panel  displays  were  used  to  display  the  sam- 
ple IDS  screens,  and  WindRiver°’s  VxWorks®  real-time 
operating  system  was  used  to  isolate  the  developed  soft- 
ware from  the  hardware.  Several  other  COTS  products, 
including  a Radstone6  CPU  board,  were  also  evaluated 
as  alternatives  to  the  above  configuration  as  part  of  the 
ASTI  program. 

During  IDS  exploration  and  development,  several  indus- 
try standard  processes  and  tools  were  evaluated.  One  of 
the  main  tools  explored  was  Virtual  Prototype0^  VAPS® 
product,  which  allows  quick  creation  and  demonstration 
of  display  screens. 
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Fig.  1.  DAU  system  architecture. 


Fig.  3.  Sample  IDS  display. 
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VAPS®  provides  a graphical  user  interface  (GUI)  that 
permits  point-and-click  design  and  demonstration  of  po- 
tential IDS  display  formats.  It  also  provides  a tool  to 
convert  the  display  formats  into  C-code  that  can  then  be 
compiled  and  executed  on  many  different  target  systems. 
One  of  the  ASTI  program’s  goals  was  to  successfully 
port  the  generated  C-code  into  the  real-time  hardware, 
and  use  it  to  generate  and  update  the  displays  in  real 
time.  During  this  process,  several  problems  related  to 
porting  the  C-code  to  the  DY4°  platform  were  encoun- 
tered. But  with  help  from  Virtual  Prototypes®  and  DY4® 
support  personnel,  the  problems  were  quickly  overcome. 
However,  the  final  determination  was  that  the  update  rate 
of  the  VAPS®-generated  code  was  too  slow  to  be  directly 
applied  on  the  selected  hardware  platform,  and  that  vali- 
dation and  certification  of  the  generated  code  might  be 
difficult. 

Once  the  VAPS®-generated  code  was  deemed  unusable 
for  real-time  use  on  the  selected  hardware  platform,  a 
library  of  C++  objects  was  developed  to  allow  easy  gen- 
eration of  IDS  display  formats  in  real-time  software. 
The  Bell  Avionics  Prototyping  and  Real-time  Software 
(BARS)  library  contains  objects  to  display  any  of  the 
following  instrument  types  at  any  position,  rotation,  or 
size: 

• Dial  - Standard  circular,  or  partially  circular, 

instruments  with  user  defined  indicators. 

• Text  - Digital  readouts. 

• Ribbon  - Vertical  bar  that  indicates  the  current 

value  by  its  height. 

• Warning/Caution/Advisory  - Matrix  of  cells  that 

display  system  messages. 

• Tape  - Horizontal  region  that  can  be  used  to 

display  current  heading  information. 

• Ruler  - Vertical  or  horizontal  “ruler”  with  an 

indicator  pointing  to  the  current 

value. 

• Attitude  - Attitude  indicator. 

The  same  IDS  displays  were  recreated  using  the  BARS 
library,  and  the  hardware  was  easily  able  to  achieve  the 
desired  update  rate.  The  BARS  software  was  designed 
using  a layered  approach  in  order  to  ease  the  transition 
between  hardware  platforms.  All  BARS  graphical  com- 
mands are  based  on  the  industry  standard  graphical  lan- 
guage called  OpenGL®.  Certain  hardware  vendors  may 
supply  an  OpenGL  library;  those  that  don’t  would  re- 
quire modification  of  an  existing  library  to  allow  inter- 
facing into  their  unique  vendor  software. 


Open  architecture  concepts  were  used  at  the  system 
level,  such  that  any  COTS  display  that  can  be  pro- 
grammed with  C++  (or  C with  some  BARS  modifica- 
tions) and  that  provides  an  ARINC  429  interface  is  a 
viable  option  for  use  in  this  architecture.  In  fact,  the 
process  of  rehosting  the  software  into  a new  graphical 
hardware  system  was  demonstrated  using  the  Radstone® 
hardware.  Another  method  used  to  keep  the  architecture 
open  was  the  use  of  OpenGL  in  the  layered  software 
design  previously  described.  OpenGL  is  increasingly 
supported  by  vendors,  so  the  need  for  the  user  to  create 
an  OpenGL  interface  for  each  new  display  unit  should 
diminish. 

The  results  of  the  IDS  exploration  include  a software 
library  toolset  that  can  easily  be  used  to  generate  IDS 
displays  and  can  easily  be  ported  to  new  hardware  plat- 
forms, a standard  interface  into  display  systems,  and  a 
list  of  potential  vendors  for  such  display  systems. 

Mission  Computer.  A generic  definition  of  a “mission 
computer”  is  a system  that  coordinates  and  disseminates 
information.  It  is  responsible  for  requesting  information 
from  data  collection  systems  (such  as  the  DAU),  possibly 
altering  the  information  in  some  manner,  and  then  send- 
ing that  information  to  other  systems. 

The  COTS  options  explored  on  the  ASTI  program  were 
very  similar  to  those  explored  in  the  DAU  and  IDS  ef- 
forts. An  off-the-shelf  VME  chassis  was  selected  due  to 
industry-wide  acceptance.  There  are  numerous  vendors 
that  provide  CPU  and  communication  cards  for  the  VME 
chassis.  In  order  to  isolate  the  software  from  the  hard- 
ware, WindRiver°’s  VxWorks®  real-time  operating 
system  was  used.  The  use  of  an  operating  system  al- 
lowed the  interchange  of  CPU  and  communication  cards 
from  different  vendors. 

Improved  system  and  software  processes  learned  on  the 
ASTI  program  will  provide  additional  benefits  to  mission 
computer  development  in  the  future.  The  use  of  defined 
processes,  with  reuse  in  mind,  aided,  and  will  continue  to 
augment,  the  development  of  a suite  of  software  modules 
that  can  be  reused  repeatedly  with  only  minor  modifica- 
tions. There  will  always  be  unique  portions  of  mission 
computers;  however,  if  developed  correctly  using  open 
architecture  concepts,  there  will  be  a large  quantity  of 
reusable  system  software. 

In  the  mission  computer  case,  open  architecture  concepts 
tied  in  very  closely  with  the  use  of  COTS  systems  and 
components.  By  selecting  an  industry  standard  VME 
chassis,  an  open  architecture  was  effectively  created. 
Taking  this  a step  further  and  requiring  the  use  of  a real- 
time operating  system  like  VxWorks®  made  for  an  even 
more  desirable  environment.  This  environment  easily 
suDnorted  each  of  the  key  components  of  open  systems: 
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• Interoperability 

• Portability 

• Scalability 

The  investigation  into  mission  computers  and  their  ar- 
chitecture provided  good  insight  into  the  benefits  of 
COTS  hardware  and  software,  improved  system  and 
software  processes,  and  open  architecture  ideas.  This 
insight  will  significantly  aid  in  new  product  development 
as  well  as  subcontract  management  of  current  and  future 
mission  computer  applications. 

The  efforts  of  the  ASTI  program  resulted  in  the  follow- 
ing list  of  accomplishments: 

• Dual-use  data  acquisition  system  hardware  and 
software  using  COTS  components. 

• BARS  software  components  for  design,  evaluation, 
and  real-time  use  in  instrument  display  systems. 

• An  increased  awareness  of  the  advantages  of  open 
system  architectures. 

These  lessons  learned  are  already  being  applied  to  both 
military  and  commercial  programs.  ASTI  not  only  pro- 
vided this  concrete  list  of  accomplishments,  it  also  pro- 
vided an  increased  knowledge  base  that  will  improve  in- 
house  development  and  subcontract  management  now 
and  into  the  future. 

In  short,  commercial  off-the-shelf  parts  and  processes, 
improved  system  and  software  processes,  and  open  ar- 
chitecture concepts  can  not  only  provide  more  elegant 
solutions,  but  solutions  that  are  also  more  cost  effective 
for  military  as  well  as  commercial  businesses. 

Supplier  Selection 

Selection  of  vendors  has  long  been  a function  of  lowest 
cost  with  compromises  made  in  technical,  program  man- 
agement, and  past  performance  areas.  The  mandate  to 
select  the  “best  value”  supplier  has  forced  the  source 
selection  group  to  scrutinize  their  previous  process  for 
competitive  procurement,  and  to  modify  their  definition 
and  implementation  of  “best  value”.  History  has  shown 
that  cost  has  driven  the  procurement  decision,  while 
technical  scores  tended  to  cluster  together,  with  small 
score  differences  even  if  there  were  large  technical  dif- 
ferences in  the  proposals.  Recent  selections  have  placed 
more  emphasis  upon  technical  and  past  performance 
scoring,  and  have  normalized  proposal  scores  so  that 
technical  and  past  performance  scores  have  more  weight 
in  the  final  score,  and  therefore,  the  supplier  selection. 
Two  examples  include  the  H-l  Upgrade  Program  selec- 
tion of  Litton  for  major  cockpit  subsystem  supplier,  and 


the  V-22  Full  Flight  Simulator  selection  of  FlightSafety 
International  as  the  supplier  of  simulator  elements. 

AIRCRAFT-LEVEL  INTEGRATION  FACILITIES 

Another  risk  reduction  activity  that  reduces  the  cost  of 
mission  equipment  package  development  and  provides 
confidence  in  the  overall  success  of  an  aircraft  upgrade 
program  is  an  aircraft-level  integration  capability.  Sub- 
system development,  when  tested  within  the  supplier’s 
environment,  then  must  be  commingled  with  all  other 
components  of  the  mission  equipment  package  to  be  put 
through  the  rigors  of  aircraft-level  testing.  Typically, 
these  subsystems  have  been  tested  via  interface  protocols 
with  emulated  signal  and  sensor  inputs,  but  have  not  re- 
ceived actual  communication  from  aircraft  avionics. 
Aircraft-level  systems  integration,  which  includes  sys- 
tematic tests  which  may  be  run  in  batch  form,  are  con- 
ducted on  the  aircraft  integration  bench,  and  any  prob- 
lems found  are  scrutinized  to  identify  the  subsystem  at 
fault,  the  root  cause,  and  any  necessary  workarounds  or 
fixes. 

Over  the  past  fifteen  years,  Bell  has  evolved  a high  com- 
petence level  in  the  design  and  fabrication  of  aircraft- 
level  systems  integration  benches.  This  evolution  began 
with  the  Model  400  bench  to  provide  cockpit  subsystem 
developers  with  the  capability  to  test  their  units  in  the 
context  of  the  aircraft,  and  includes  breakout  of  all  air- 
craft signals,  emulation  of  these  signals,  setting  and 
clearing  aircraft  faults  that  annunciate  Warnings,  Cau- 
tions, and  Advisories.  Tests  can  be  repeated  and  opti- 
mized via  automation.  This  evolutionary  development  of 
aircraft-level  bench  test  capability  migrated  to  all  other 
Bell  programs.  For  example,  the  OH-58D,  CFUTTH, 
Bell-Boeing  V-22,  H-l  Upgrade  Program,  and  Bell- 
Agusta  609  programs  all  have  utilized  aircraft-level  inte- 
gration benches,  which  are  still  in  use  for  those  programs 
with  ongoing  upgrades,  modifications,  or  field  problems. 

For  past  integration  benches.  Bell  utilized  a set  of  cards 
developed  in-house,  called  Universal  Electronic  Test  Set 
(UETS)  cards,  which  contained  the  capability  to  emulate 
sixteen  signals  of  discrete,  analog,  monopole,  thermo- 
couple, and  other  types  of  signals  and  sensors.  One 
chassis  could  house  up  to  sixteen  cards,  and  a set  of  three 
chassis  could  be  accommodated  in  one  rack.  The  Bell- 
Boeing  V-22  Electronic  Systems  Test  Lab  (VESTL) 
utilizes  two  racks — or  a total  of  over  2,000  signals  in  the 
mission  equipment  package.  Software  to  control  these 
signals,  and  to  communicate  with  the  aircraft  systems, 
was  coded  in  C++,  also  in-house. 

COTS  technology  specifically  geared  for  testing  has 
advanced,  and  so  for  new  aircraft-level  benches,  Bell  is 
instituting  a new  set  of  hardware  and  software 
constructed  to  test  all  aircraft  subsystems,  both  in  the 


*, 
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hardware  and  software  domain,  and  with  the  option  of 
automating  tests  using  new  scripting  features.  These 
new  components  are 

• VME  National  Instruments  Mxi®  interface  - PCI  to 
VME  memory  space  converter. 

• LabWindows  CVI®  - test  software  package. 

• Windows  NT®  - operating  system. 

The  Bell-developed  integration  benches  are  designed 
for  portability,  and  can  be  broken  down  quickly  for 
transport  to  any  aircraft  test  site.  The  V-22  test  bench 
has  been  disassembled  and  moved  to  the  location  of 
aircraft  flight  test  in  support  of  the  Engineering 
Manufacturing  Development  program,  and  will  be 
disassembled  and  moved  again  to  support  Low  Rate 
Initial  Production. 

The  fabrication  of  two  aircraft-level  integration  bench 
facilities  is  currently  in  progress:  one  for  the  H-l 


Upgrade  Program,  and  one  for  the  Bell-Agusta  609  pro- 
gram. The  H-l  Integrated  Test  Station  Floor  Plan  is 
depicted  in  Fig.  4,  followed  by  a diagram  of  the  bench 
architecture  in  Fig.  5. 

The  Bell-Agusta  609  Vehicle  Management  Systems 
Integration  Lab  (VMSIL),  also  in  development, 
represents  the  most  complex  and  robust  integration 
bench  ever  built  at  Bell.  It  provides  three  separate 
system  test  capabilities:  one  for  the  avionics  systems,  one 
for  the  electrical  systems,  and  one  for  the  flight  control 
system.  These  can  be  employed  independently  or 
simultaneously  based  upon  test  requirements.  This 
bench  also  ties  in  the  aircraft  math  model  via  a Silicon 
Graphics  host  machine,  which  allows  complete  testing  of 
the  flight  control  system.  Test  scripts  have  been  written 
to  provide  batch  test  capability  for  rapid  system  testing 
for  software  and  hardware  releases  to  the  VMSIL.  In 
addition,  the  VMSIL  has  mission  record  and  playback 
capability,  which  will  make  anomaly  investigation 
easier.  A block  diagram  of  the  Bell-Agusta  609  VMSIL 
is  included  as  Fig.  6. 
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Fig.  4.  H-l  integrated  test  station  floor  plan. 
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HI  Integrated  Test  Station 
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Fig.  5.  H-l  integrated  test  station  bench  architecture. 
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Fig.  6.  Bell-Agusta  VMSIL  data  system  architecture. 


TRAINING  SYSTEMS 

In  order  to  minimize  actual  aircraft  test  time  for  crews 
and  maintained,  it  is  important  that  economical,  off- 
aircraft  training  is  available  and  concurrent  with  the  air- 
craft configuration. 

Training  needs  can  be  met  with  simulation  trainers,  such 
as 

• Engineering  simulators. 

• Flight  simulators,  with  and  without  motion. 

Engineering  simulation  is  necessary  for  cockpit 
development,  and  provides  interaction,  familiarization, 
and  hands-on  experience  for  pilots,  customers,  and 
crew  systems  developers.  Bell  has  an  outstanding 
capability  in  the  engineering  simulation  environment, 
where  cockpit  studies  yielded  optimal  design  and 
development  of  handling  qualities,  flight  control  laws, 
crew  station  ergonomics,  and  cockpit  displays  for  the  V- 
22  aircraft  with  variants,  as  well  as  for  the  H-l  Upgrade 
Program.  The  Bell  engineering  simulation  is  performed 
using 

• ES1G  4530°- Visual  system. 


• SGI  Origin  2000u-  host  computer. 

Flight  simulation  is  the  next  step  for  crew  training,  and 
Bell  is  in  the  forefront  of  state-of-the-art  development  on 
its  V-22  Full  Flight  Simulator  (FFS)  program.  Bell- 
Boeing  selected  FlightSafety  International  (FSI)  as  a 
design  partner,  and  each  partner  has  fulfilled  design  re- 
quirements for  those  areas  in  which  they  excel.  The 
worksplit  between  Bell  and  FSI  on  the  V-22  FFS  was 
determined  to  maximize  core  capabilities  both  Bell  and 
FSI:  Bell  is  responsible  for  technical  oversight,  the  aero 
performance  model,  math  model  shared  memory,  avion- 
ics subsystems  (a  combination  of  emulation  and  stimula- 
tion), data  interchange,  displays,  and  aural  alerting,  and 
FSI  is  responsible  for  providing  the  visual  system,  the 
cockpit  and  cab,  and  the  test  stations.  The  FFS  is  cur- 
rently ahead  of  schedule  and  is  underspent,  and  is  ex- 
pected to  deliver  up  to  five  months  earlier  than  its  sched- 
uled December  2000  delivery  date,  to  New  River,  North 
Carolina,  to  begin  24-hour-a-day,  7-day-a-week  training 
for  the  customer. 

With  aircraft  concurrency  as  a requirement  for  the  V-22 
FFS,  Bell-Boeing  conducted  trade  studies  in  order  to 
determine  those  avionics  components  most  likely  to  be 
frequently  modified,  and  utilized  actual  aircraft 
components  for  those  items.  For  example,  the  mission 
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computers  for  the  V-22  frequently  undergo  software 
modifications  to  add  functionality  or  resolve  problems, 
and  so  the  actual  aircraft  units  are  used  on  the  FFS, 
although  when  the  mission  computer  development  is 
considered  mature,  the  mission  computer  function  will 
be  emulated.  Other  subsystems  are  also  emulated  in  the 
aircraft  software  for  the  FFS.  When  software  changes 
are  made  to  the  aircraft  mission  equipment,  they  can  be 
easily  and  rapidly  rolled  into  the  V-22  FFS 
configuration,  thus  keeping  the  training  concurrent  with 
the  aircraft. 

In  addition,  with  commonality  between  devices  a cus- 
tomer desire.  Flight  Training  Devices  (FTD)  also  con- 
tracted by  the  customer  for  the  V-22  program  will  be 
implemented  with  the  same  hardware  and  software  as  is 
the  V-22  FFS,  with  the  exception  of  the  motion  base. 
This  approach  minimizes  non-recurring  cost,  and  pro- 
vides the  customer  an  FTD  before  its  scheduled  due  date. 
Updates,  spares,  and  maintenance  issues  are  addressed 
identically  for  both  training  device  types.  Fig.  7 shows 
the  V-22  FFS  integration  architecture  block  diagram. 

SUMMARY 

Aircraft  manufacturers  face  tremendous  challenges  in 
today’s  military  environment  where  the  customer’s  de- 
sire for  cutting  edge  technology  frequently  outstrips 
available  funding.  The  challenge  for  Bell  and  other  air- 
craft manufacturers  is  to  meet  customer  expectations 


while  maintaining  the  delicate  balance  between  cost, 
development  time,  and  performance. 

In  order  to  meet  this  challenge,  it  is  imperative  that  air- 
craft manufacturers  improve  their  technological  expertise 
and  their  development  processes.  This  means  a corpo- 
rate commitment  that  may  require  internal  investment. 

Discipline  in  systems  engineering  can  yield  outstanding 
results  in  aircraft  upgrade  implementation,  particularly  in 

• Definition  of  the  mission  equipment  package. 

• Delineation  of  the  mission  equipment  package  ar- 
chitecture. 

• Allocation  of  requirements  to  the  aircraft  subsys- 
tems. 

• Selection  of  suppliers  that  meet  subsystem  require- 
ments with  strong  technical  solutions  and  past  his- 
tory of  program  success. 

• Collection  of  “lessons  learned”  at  aircraft  upgrade 
program  completion. 

• Investment  in  process  improvements: 

1 . In-house  avionics  development. 

2.  Smart  buyers  of  avionics  from  outside  suppliers. 


Audio 


Fig.  7.  V-22  FFS  integration  architecture. 
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• Investment  in  product  development  knowledge. 

• “Best  value”  supplier  selection. 

Following  the  detailed  design  and  development  period  of 
an  aircraft  upgrade  program,  all  subsystems  must  be 
assembled  at  one  point  prior  to  aircraft  installation. 
While  each  subsystem  may  be  operational  in  their 
respective  test  environments,  their  interaction  in  an 
aircraft- level  integration  environment  is  required  in  order 
to  reduce  on-aircraft  testing  and  to  resolve  anomalies  that 
could  result  in  safety  issues  on  the  aircraft.  Robust 
bench  testing,  in  a location  near  the  air  vehicle, 
particularly  during  the  development  period,  ensures  that 
aircraft  test  time  is  optimized  to  expend  flight  time  on 


only  those  functions  that  cannot  be  tested  in  a laboratory 
environment. 

Lastly,  off-aircraft  training  in  a simulated  environment 
reduces  costly  aircraft  time  for  the  development  of  cock- 
pit displays  and  ergonomics  and  for  aircrew  flight  train- 
ing. 

Bell  Helicopter  Textron  has  made  significant  invest- 
ments in  these  processes  and  technologies,  and  has  added 
“Systems  Integration”  to  its  list  of  six  core  competencies. 
For  Bell,  and  for  other  aircraft  manufacturers,  the  con- 
sideration and  institutionalization  of  these  elements  into 
the  engineering  process  adds  a powerful  tool  for  ad- 
dressing the  formidable  task  of  introducing  aircraft  up- 
grades that  are  affordable  and  provide  “best  value”  to  the 
military  customer. 


